So, there is some history of organisations doing a poor job at managing security bugs. We saw the This is not really a security hole jokes just to avoid having bad statistics in the front page. We saw the OMFG you must update to the latest version RIGHT NOW and no I m not telling why panic. We still frequently see security fixes hidden in unrelated public commits, just to make them harder to backport for distributors. But really, there is absolutely no match for that. Kudos for setting a new standard in the worse way of dealing with security issues, guys. Update: one of the developers has started insulting a pair of professional IT security experts who came and tried to educate him. Awesome reading, don t forget the popcorn.

When George Papandreou announced its will to submit the European help program to the approbation of the Greek people, I don t know whether he wanted to scare people, but man, he really achieved something. From Wall Street to the Bundestag, through the lys e Palace, they are all in a state of advanced panic. There s a joke that s been circulating since: for next Hallowe en, disguise yourself as a referendum. Yes, these guys are afraid. Afraid of the people. They are afraid because it is now clear that their interests are not the same as the interests of the people. And what do you do when you are afraid? Well, you find yourself some way out, often by lying. And indeed, Mrs Merkel and Mr Sarkozy have been repeating over and over something that has been then repeated over and over by most so-called journalists: that Greeks can only choose between two endings:

1. they pay their debts to banks and rich people, and stay in the Euro zone;
2. they don t pay their debts to banks and rich people, and find themselves another currency.

That s it: Mrs Merkel and Mr Sarkozy are outrageous liars. There is another option for Greek people:

3. they don t pay their debts to banks and rich people, and they stay in the Euro zone.

It s as simple as that: nothing in European treaties can force a country to leave the Euro zone. And nothing in these treaties can force a country to honor their bonds. Greece is a sovereign state and, as such, can choose not to honor its sovereign debt. And choose to stay in the Euro zone: why would they want to go out? What does it have to do with the currency those bonds have been emitted in? If California were to cease payment of its public debt (something not likely to happen at all, hmm?), would it have to abandon the Dollar? But here is a thing that has been forbidden for a long time in European treaties: for a country to help financially another one to pay its debts. This rule was introduced by Jacques Delors (a man who knows what being European means) precisely in order to avoid the contagion we are facing currently because of stupid help plans all across Europe. Yes: the whole idea of Merkozy s grand plan to save Euro while helping Greece (a weird kind of help, starving people, really) is illegal. So in addition to being liars, Mrs Merkel and Mr Sarkozy are delinquents. So let Greece cease payment of its debt. A few banks will sink: so what? This will create less unemployment than letting our whole economy sink. European States will guarantee citizens savings up to 30 k , that s one of the other clever European rules (some countries guarantee more). Other people, rich people only, will lose their savings. Will that prevent you from sleeping? Not me. But that could prevent from sleeping a number of friends of Mrs Merkel s and Mr Sarkozy s. And wouldn t that be a good reason for lying and violating European treaties?

This morning, when turning on TV, my ears have been yet another time hurt by the stupidity of a self-appointed economist, trying to intoxicate people with his fantasies about economy being able to regulate itself. Seriously. All neoliberals, please shut the fuck up. Now. The world has been running out of your ideas for more than 30 years. We lowered salaries and taxes, making the world run through credit. We gave everything to those who were already born with everything. Economy was almost brought to the verge of implosion thanks to your crazy ideas. For 4 years since the subprimes crisis, you psychopaths have kept on explaining it happened because we have not listened to you enough, and that the solution is to lower salaries even more. A quick look at the situation in Greece and UK should be enough to understand where this is going. It is time for something new. So shut up now, and let others fix the mess you have left behind.

The following is a quick HOWTO for the brave Debian users who want to upgrade to GNOME 3. Assuming you have an up to date system running sid, and experimental listed in your APT sources, perform the following complicated steps to end up having a functional GNOME 3 desktop:

apt-get install -t experimental gnome

Thanks go to Joss for putting together new GNOME 3 meta-packages, and the rest of the Debian GNOME people for months of hard planning and packaging work, and painful testing transition handling. Before you ask, yeah, not all of GNOME 3.x is in unstable yet, but will soon be, as precedent transitions start clearing the way. And yeah, GNOME 3.2 will come just after the two remaining package sets enter testing. To compensate, you'll find that you have some GNOME leaf packages pending an upgrade to 3.2.0-1 while you read this.

As the administrator for several MTAs I've received my fair share of support requests for "unreadable" e-mails. They generally have an attachment called winmail.dat. This is what all (for exceptions see the rest of this blog post) non-Outlook MUAs can display, when they receive an e-mail with the application/ms-tnef (or application/vnd.ms-tnef) MIME type. TNEF is a propietary format cooked up in Redmond. When chosen, the e-mail in question isn't sent as text/plain or at least text/html, but the entire e-mail is put into an TNEF-encoded attachment, most often called winmail.dat, in which you (most commonly) find the content of the e-mail in RTF, possible attachments are also put into the winmail.dat. The easieast solution for all involved parties is to convince the sender, that her Outlook and/or Exchange setup needs fixing (disabling TNEF in Outlook and Exchange 2003). Sadly this won't work all the time. The other solutions are to either filter the e-mails on your e-mail server and run them through something like ytnef_smtpd.py (please note, that this might be legally problematic for you as a service provider, opening an e-mail, even automatically, is a violation of communication privacy rights in many jurisdictions). Or, if the legal problem is too big or can't be solved through an local server installation (e.g. because there is no server running 24/7), you're left with either using Outlook (probably what Microsoft intended) or you can use a plug-in/add-on for your client. I've tested the LookOut add-on for icedove and it seems to work well. There are of course plug-ins for many other clients, but I can't honestly tell whether they work or not. [UPDATE 2011-09-20]: Fellow Debian Developer Josselin Mouette wrote me, that Evolution is capable of reading TNEF-encoded e-mails out of the box, but he also said that [TNEF e-mails should] be banned by all means.[/UPDATE 2011-09-20] Now, before I close, please always try to convince the sender/postmaster to fix their setup. It has only advantages: text/plain e-mails are smaller, they're less likely to contain malicious code (i.e. no parts hidden away from the virus scanner on the mail server (amavis can read TNEF e-mails, if libconvert-tnef-perl is installed)) and all recipients can open the e-mails with the client of their choice.

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work, then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. I have been Doing some work towards Debian Rolling At the start of the month, the discussions about Debian rolling were still very active on debian-devel. Declaring that testing would be rolling did not make it (as I hoped), the argument that some RC bugs last for far too long in that distribution carried the discussion and thus the most consensual proposition ended up being the one of Josselin Mouette were rolling would be testing plus a few selected cherry-picked packages from unstable. I believe it s a workable solution if we only care about a subset of architectures. Otherwise the same reasons that keep the fixed packages out of testing would probably also apply for rolling. Given this, I did setup britney (the software that controls testing) on my laptop to investigate how we can create rolling. It turns out britney is a very specialized software with very few configuration knobs. At the same time Joachim Breitner made a proposition that immediately grabbed my attention. He suggests to use SAT solvers to find out the set of packages that should migrate from unstable to testing. I thought that rolling would be a good testbed for this new implementation of britney (which he calls SAT-britney) so I jumped right in this project. I was not at all familiar with this science field, so I looked up quite some documentation: I learned that all SAT solvers expect the problem to be presented in CNF form, and that DIMACS was the file format of choice to represent those boolean constraints. Several SAT solvers are available in Debian and picosat appears to be one of the best. Then I started some early coding/prototyping to play with the concept. You can find the result in this git repository, you can grab a copy with git clone git://git.debian.org/~hertzog/sat-britney.git. There s not much yet, except some Python code to generate a SAT problem that can be fed to a SAT solver. But I really look forward to this project. Representing Debian during Solutions Linux During the second week, I spent 3 days in Paris to help manage the Debian booth at Solutions Linux. We have responded to lots of queries but most visitors already knew Debian, and many of them use it at work and/or at home. We tried to recruit those people as new members for Debian France, the local association. We also sold all our remaining goodies. The Ubuntu people were interviewed by France 3 (an important TV channel) and we took this opportunity (with the consent of the Ubuntu guys) to show our Debian t-shirts in the background: you can watch the video here (in French), you can see me with Carl Chenet at 1:21. We have also been interviewed by Intelli n TV: here and here (both in French). I m not very good at this exercise. Improving dpkg triggers The third week was a vacation week, in theory I should have stayed away from my computer but I really wanted to take this opportunity to improve the state of dpkg triggers in Debian. I already covered my work in another article: Trying to make dpkg triggers more useful and less painful. The result is not merged yet, I just asked a question to all package maintainers who are using triggers to be able to decide whether I ll merge it as is, or if I can make the new behavior the default one. Supporting users after Alioth s migration When I came back from my vacation, many services provided by Alioth.debian.org were non-functional after a migration to a new setup that involves two machines instead of one. Given that I used to be an Alioth admin, I know that in those periods you tend to be get bogged down on many user support requests. So I re-joined #alioth on IRC and tried to help a bit. I did investigate some of the reported problems and prepared fixes (updated scripts, configuration files, etc.) for some of the issues. I also created a list of remaining issues that should have lasted only a few days but that s still active because there are still regressions left. The most important things still missing are:

• proper support for delegation of rights. We used ACL setup by the admins in the past. With the new FusionForge, each project admin should be able to delegate rights to external roles . There s a Debian Developer role already but trying to grant him right fails
• access to the Ultimate Debian Database. Many tools rely on this database to work.
• anonymous FTP access to download project files.
• clear guidelines on how we re supposed to deal with websites that are updated by VCS hooks.
• clear guidelines on how we re supposed to deal with personal git repositories

Improving the 3.0 (quilt) source format I have made some proposals to change the way the new source format would work. The goals are to be less painful for packagers who are using a VCS, and to avoid unexpected changes slipping through a new patch generated by dpkg-source. It seems that the proposals are relatively consensual so I ll implement them at some point. Missing in action on my blog I did a lots of stuff for Debian between travel and vacation, and in the remaining time, I did not manage to write many articles for my blog. In fact, besides the article on my triggers work mentioned above I only published one interview: People behind Debian: Steve Langasek, release wizard. I ll try to do better this month! Thanks Many thanks to the people who gave me 151.61 in May. See you next month for a new summary of my activities.

One comment Liked this article? Click here. My blog is Flattr-enabled.

So I just read that Google will only support modern browsers starting 2 months from now.

As of August 1st, we will discontinue support for the following browsers and their predecessors: Firefox 3.5, Internet Explorer 7, and Safari 3. In these older browsers you may have trouble using certain features in Gmail, Google Calendar, Google Talk, Google Docs and Google Sites, and eventually these apps may stop working entirely.

Given the importance of Google, the impact is huge. This company has acquired the power to basically dictate what browser you can provide to your users - otherwise they won t be able to access what many of them now consider vital functionality. Such a decision denotes a grave misunderstanding of the workstation ecosystem from the Google people. It means they consider their only target to be nerdy users with home computers they can (and want to) upgrade and break every 3 months with the latest version of Windows or Fedora. What about corporate computers? What about non-techy people who buy a computer and stick with the OS that was sold with it for 4 years? I m afraid they are still the vast majority of web users. You can t decide to deploy a new version of IE of Firefox on a large number of computers for next month. Sometimes, this is not even possible (hello Windows 2000/XP users). For Debian squeeze, this means no more Firefox for you. Epiphany and Konqueror might still work, but Google loves sending JavaScript that make old versions of Webkit struggle. And anyway, this is just the beginning. In a few months they will tell us to upgrade again to Firefox 4.2 and IE 12. One week after their release, yeah! Let s quote a comment which should help understanding the reasoning behind such decisions.

Andy, while I understand staying on LTS, I think it's a little bit silly to use a mission critical machine for web browsing in that way. Also, there is no reason your browser has to be tied in lockstep to your OS. Two simple solutions:
1. Don't use the built-in browser for your main web browsing. Install Chrome, for example. or,
2. Since LTS is designed for servers and other "can't have any chance of downtime" machines, quit using that machine as your web browsing box and use a personal laptop for such things, which you can keep up to date with the current OS release instead of waiting 2 years.

Belief #1: the browser can (and should) be independent from the OS . It s interesting to note that the same people who say this are the ones who also jerk off at the idea of desktops and phones with tight web integration. This integration comes at a cost: this restricts your ability to change everything in the browser from one day to another. Belief #2: long-term OSes are for mission-critical servers only . Yeah sure, that s why Windows has a lifecycle of 3 years. Desktops are no different at all from servers on this matter. You don t upgrade your desktop every 6 months when you do serious work with it; the cost and the risk are just too high. And anyway, this comes again from the same people who want to upgrade every single component of said mission-critical servers every 2 months to install the latest version of their preferred web framework. Belief #3: people can upgrade their browsers or OSes . No really they can t. Many people wouldn t know how to do this, even with a step-by-step documentation. And in enterprise deployments, they are restricted from doing so. Thanks for spreading the clich that web developers are clueless, spotty nerds, incapable of understanding the needs of production environments. Apparently Google is not exempt from this disease.

Since this has been a major request from users for a long time, I can only cool with the idea of seeing the Debian project support a rolling release. However I m not pleased with the proposed ideas, since they don t actually include any serious plan to make this happen. Sorry guys, but a big GR that says We want a pony rolling release to happen doesn t achieve anything. Let me elaborate. First of all, discussions have focused a lot on what to do when we re in a freeze phase. Numerous cool ideas have been proposed, including PPAs (which again, won t happen until someone implements them). This is all good, but this is only the tip of the iceberg. Above all, before wondering what can happen in a freeze that lasts 20% of the time, let s wonder what can happen for the 80% remaining time. Once you have something that works in the regular development phase, you can tune it to make it happen, even if in a less optimal way, when the distribution is frozen. So let s not put the cart before the horse. There are three options if you want to make a rolling release happen.

1. Make unstable usable. to make it happen, you have to prevent the disasters that rarely but unavoidably happen here. You don t want to make all rolling systems unusable because someone broke grub or uploaded a new version of udev that doesn t work with the kernel.
2. Make testing usable. This sounds easy since RC-buggy packages are already prevented from migrating, but actually it is not. A large number of RC bugs are discovered at the time of testing migration, when some packages migrate and others don t. Worst of all, they require several days to be fixed, and it is very often that they require several months, when one of the packages gets entangled in a transition.
3. Create a new suite for rolling usage.

The proponents of the CUT project obviously believe in option 2. Unfortunately, I haven t seen many things that could make it happen. A possible way to fix the situation would be to run large-scale regression testing on several upgrade paths. I don t know if there are volunteers for this, but that won t be me. That would also imply to make a lot of important bugs RC, since they could have a major effect on usability, but the release team will not be keen to make it happen. Because of the testing situation, when someone asks me for a rolling release, I point her to unstable with apt-listbugs. As of today, this is the closest thing we have to a rolling release, so we should probably examine more deeply option 1. Is it that complicated to write a tool to prevent upgrades to broken packages? A 2-day delay in mirror propagation and a simple list of broken packages/versions (like the #debian-devel topic, would be enough. Add an overlay archive, that works like experimental, and you can now handle freezes smoothly. Wait isn t that aptosid? We would probably gain a lot of insight from the people who invented this, instead of trying to reinvent the wheel. Finally, option 3 could open new horizons. There s a risk that it might drive users away from the testing and unstable suites, and this makes us wonder how we could have proper testing for our packages. Still, build a process that would (and that s really only an example) freeze unstable every month, give people 10 days to fix the most blatant issues, add a way to make security updates flow in from unstable, and you have a really nice rolling distribution. So overall, it only requires people to make things happen. You want option 2 to happen? Instead of working on GR drafts, start working with maintainers and release managers on ways to avoid breakage in testing. You want option 3 to happen? Start it as a new .debian.net service and see how it works. Personally, I d be in favor of offering aptosid developers to become DDs and offer their solution as a Debian service. It would bring in new people rather than driving away existing developers from working on our releases.

With all the buzz around GNOME 3, I really wanted to try it out for real on my main laptop. It usually runs Debian Unstable but that s not enough in this case, GNOME 3 is not fully packaged yet and it s only in experimental for now. I asked Josselin Mouette (of the pkg-gnome team) when he expected it to be available and he could not really answer because there s lots of work left. Instead Roland Mas gently answered me Sooner if you help . First steps as a GNOME packager This is pretty common in free software and for once I followed the advice, I spent most of sunday helping out with GNOME 3 packaging. I have no prior experience with GNOME packaging but I m fairly proficient in Debian packaging in general so when I showed up on #debian-gnome (irc.debian.org) on sunday morning, Josselin quickly added me to the team on alioth.debian.org. Still being a pkg-gnome rookie, I started by reading the documentation on pkg-gnome.alioth.debian.org. This is enough to know where to find the code in the SVN repository, and how to do releases, but it doesn t contain much information about what you need to know to be a good GNOME packager. It would have been great to have some words on introspection and what it changes in terms of packaging for instance. Josselin suggested me to start with one of the modules that was not yet updated at all (most packages have a pre-release version usually 2.91 in experimental, but some are still at 2.30). Packages updated and problems encountered (You can skip this section if you re not into GNOME packaging) So I picked up totem. I quickly updated totem-pl-parser as a required build-dependency and made my first mistake by uploading it to unstable (it turns out it s not a problem for this specific package). Totem itself was more complicated even if some preliminary work was already in the subversion repository. It introduces a new library which required a new package and I spent a long time debugging why the package would not build in a minimalistic build environment. Indeed while the package was building fine in my experimental chroot, I took care to build my test packages like the auto-builders would do with sbuild (in sid environment + the required build-dependencies from experimental) and there it was failing. In fact it turns out pkg-config was failing because libquvi-dev was missing (and it was required by totem-pl-parser.pc) but this did not leave any error message in config.log. Next, I decided to take care of gnome-screensaver as it was not working for me (I could not unlock the screen once it was activated). When built in my experimental chroot, it was fine but when built in the minimalistic environment it was failing. Turns out /usr/lib/gnome-screensaver/gnome-screensaver-dialog was loading both libgtk2 and libgtk3 at the same time and was crashing. It s not linked against libgtk2 but it was linked against the unstable version of libgnomekbdui which is still using libgtk2. Bumping the build-dependency on libgnomekbd-dev fixed the problem. In the evening, I took care of mutter and gnome-shell, and did some preliminary work on gnome-menus. Help is still welcome There s still lots of work to do, you re welcome to do like me and join to help. Come on #debian-gnome on irc.debian.org, read the documentation and try to update a package (and ask questions when you don t know). Installation of GNOME 3 from Debian experimental You can also try GNOME 3 on your Debian machine, but at this point I would advise to do it only if you re ready to invest some time in understanding the remaining problems. It s difficult to cherry-pick just the required packages from experimental, I tried it and at the start I ended up with a bad user experience (important packages like gnome-themes-standard or gnome-icon-theme not installed/updated and similar issues). To help you out with this, here s a file that you can put in /etc/apt/preferences.d/gnome to allow APT to upgrade the most important GNOME 3 packages from experimental:

Package: gnome gnome-desktop-environment gnome-core alacarte brasero cheese ekiga empathy gdm3 gcalctool gconf-editor gnome-backgrounds gnome-bluetooth gnome-media gnome-netstatus-applet gnome-nettool gnome-system-monitor gnome-system-tools gnome-user-share baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-system-log gstreamer0.10-tools gucharmap gvfs-bin hamster-applet nautilus-sendto seahorse seahorse-plugins sound-juicer totem-plugins remmina vino gksu xdg-user-dirs-gtk gnome-shell gnome-panel dmz-cursor-theme eog epiphany-browser evince evolution evolution-data-server file-roller gedit gnome-about gnome-applets gnome-control-center gnome-disk-utility gnome-icon-theme gnome-keyring gnome-menus gnome-panel gnome-power-manager gnome-screensaver gnome-session gnome-settings-daemon gnome-terminal gnome-themes gnome-user-guide gvfs gvfs-backends metacity mutter nautilus policykit-1-gnome totem yelp gnome-themes-extras gnome-games libpam-gnome-keyring rhythmbox-plugins banshee rhythmbox-plugin-cdrecorder system-config-printer totem-mozilla epiphany-extensions gedit-plugins evolution-plugins evolution-exchange evolution-webcal gnome-codec-install transmission-gtk avahi-daemon tomboy network-manager-gnome gnome-games-extra-data gnome-office update-notifier shotwell liferea epiphany-browser-data empathy-common nautilus-sendto-empathy brasero-common
Pin: release experimental
Pin-Priority: 500
Package: *
Pin: release experimental
Pin-Priority: 150

The list might not be exhaustive and sometimes you will have to give supplementary hints to apt for the upgrade to succeed, but it s better than nothing. I hope you find this useful. I m enjoying my shiny new GNOME 3 desktop and it s off for a good start. My main complaint is that hamster-applet (time tracker) has not yet been integrated in the shell.

21 comments Liked this article? Click here. My blog is Flattr-enabled.

Today we gathered the representatives of different distributions that are present at GNOME.Asia to discuss what GNOME could do to improve its support for distributions that distribute it, especially in matters of long-term support. It is kind of sad that there weren t any representatives from Canonical nor Red Hat, but the discussion turned out really interesting and we learned a lot about the packaging habits of each other. Furthermore, there were several concrete leads that were explored, which will lead to proposals from the GNOME foundation to all distributions. Helping with long-term support The most widespread GNOME version in the LTS releases that happened recently is 2.30, which is used by Debian squeeze, Ubuntu LTS 10.04, RHEL 6, and Solaris 11. It looks like an accident, but on the other hand:

• GNOME 2.32 isn t really suitable as is for an entreprise distribution;
• Linux distributions agreed on a kernel version to support long-term, so this had an impact on their release schedules, and this might well happen again for the next release.

In the future, a decision to use a common GNOME release could, anyway, only come from the distributions themselves, not from GNOME. A proposal that many people agreed upon was to give distribution maintainers commit access to old branches that GNOME module maintainers don t touch anymore. This way they could share their patches more easily and make new releases of these old branches. This would imply, of course, setting up rules about what changes are allowed, that distributions would have to agree upon (how to treat feature additions for example). Managing bugs Currently it is hard to tell, for a distributor, whether other distributions are affected too and whether they have released a fix for that. It was agreed upon that Launchpad s feature of linking bugs between distributions, including version tracking, would exactly fill that need. One of the solutions would then be to add such a feature to Bugzilla, but it is a lot of work since currently it doesn t have any kind of version tracking. Another proposal was to deploy a new Launchpad instance to do serve as a hub between downstream bug systems and the GNOME Bugzilla. The condition for this to work would be to make it extremely easy to clone bugs between it and Bugzilla, and also if possible from the downstream bug systems. On the side-related topic of how not to crawl under bugs, it might be possible to get bugs forwarded with a single command from the Debian BTS to Bugzilla, using the XML-RPC interface. Upstream also considers that bugs sent to Debian are generally of higher quality than those from e.g. Ubuntu, and would be OK with us routing some of them directly to upstream (like we already do for Evolution). Communicating about the availability of patches Currently distributors are hardly ever informed that patches relevant for their distribution have been committed. They often learn of them by sheer luck while lurking on Bugzilla. The distributors-list ML is clearly the relevant media for that purpose, but it is clearly not used enough. It would need to be advertised more among both GNOME module maintainers, and among downstream maintainers as well. On this matter, the disappearance of the x.y.3 GNOME releases (starting with 2.28) was evoked. The problem was that most of those releases were about insufficient changes to justify e.g. stable updates in distributions. The proposed solution is to encourage maintainers of modules with bugs to fix to release new versions (through an annoucement on desktop-devel-announce), and to send a list of modules with new versions to downstream distributors so that they can integrate them. This avoids the GNOME release team the hassle of making a new release, while still giving distributions that use them some bugfixes. Providing a new service to LTS distributions The idea of having the GNOME foundation employ a person to gather, on the GNOME side, all changes that are relevant to older GNOME versions, and prepare new stable versions, was discussed. This would be a new service for which commercial distributions would need to pay a fee. It s not clear how this information would be privately disclosed and the impact on non-commercial distributions. But it doesn t seem likely that e.g. Red Hat would be interested since they employ a lot of core GNOME hackers who are already doing this job.

---

I don t know what impact these proposals can have on GNOME packaging in Debian, but apart from the last one that I find dubious, it seems that they could greatly improve our support of GNOME in stable Debian releases, be it by having more versions to upload during the freeze, or by having more stuff in point releases. Fr d ric Muller promised to come back to us with more concrete stuff.

For the whole week, I ve been in Bangalore for the GNOME.Asia 2011 hackfest. I ve been delegated by Stefano to represent Debian here, and my employer EDF has agreed to cover for travel costs since they are very interested in first-hand information the future of the Linux desktop and sharing our work on scientific computing. It s been a really exciting week; I ve spent quite some time packaging missing pieces of GNOME 3.0 (well, the release candidate versions of course) in experimental, together with Fred Peters. I think it s reaching a usable state now, so we ll probably soon provide metapackages to make it easily installable. The latest developments of the Shell make it a very exciting piece of software, with a strong focus on usability. Many things were written about it, but in the end my main criticism would be that it lacks some functionality - for example, the combined clock/weather/locations applet will be greatly missed. The good news is that it is extremely customizable, and with all the libraries being made accessible through GObject introspection, there are many features that are accessible from it. If you know how to write JavaScript, now is the time to write your favorite extension. On the good news front, Vincent Untz also spent a lot of time improving the so-called legacy mode , which is more and more starting to look like the Shell without special effects, and with all the features from gnome-panel 2.x that are still here. We will try in Debian to cover all uses cases that there were for GNOME 2 with GNOME 3 technology, so that panel lovers are not left behind. I ve also proposed an update to the dh_gsettings proposal, which will provide the same functionality as dh_gconf and allow to easily set distribution-specific overrides. It is still missing a way to set mandatory settings, which might come as a problem for some corporate users, but this is planned for a future version of GSettings. Today, we re having a business track where I and representatives of other companies (Oracle, Lanedo, Dexxa) are sharing experiences about making money with free software. Unfortunately the local organizers didn t manage to gather many people, despite our being in a city with an incredible number of IT industries. Tomorrow, the public conference starts, and this should be the opposite: we re expecting around 1000 people, which is a great achievement for a free software conference. For an unrelated topic, being around so many GNOME hackers has some interesting side effects; I ve been added to Planet GNOME. So, hey, hello Planet GNOME readers!

There have been a lot of web browsers embedding the Gecko engine, especially through the gtkmozembed library (it was not really a proper library but let s call it like that). I remember being a happy user of galeon, which went on as epiphany, but there were also all these small applications that just need a good HTML renderer in one of their widgets, like yelp, or several Python applications using python-gtkmozembed. Anyone having had to deal with these applications, especially the most complex ones, could tell you a few things:

• the Mozilla developers never gave a friggin damn about embedding;
• they don t know how to develop an easily embeddable library;
• the notion of a stable interface is a very arcane concept that they don t wish to grasp.

So, today, it is official: Mozilla is dropping gtkmozembed from their codebase. I don t think this will come as a surprise to anyone. You can t develop a new version of a behemoth, monolithic application every 3 months while still caring about the interfaces underneath. Embedded applications have been migrating to webkit over the recent years, and those that don t do it really soon will die. The interesting part of the announcement is not here. It can be found hidden in a bug report: a stable and versioned libmozjs will just never happen. What does it mean? First of all, it means that Debian and Ubuntu will have to go on maintaining their own versioning of libmozjs so that it can be linked to in a decent way by applications using the SpiderMonkey JS engine. It also means that this version will have to be bumped more often. But it also puts into question the whole future of SpiderMonkey as a separate library. With a shortened release cycle, the Mozilla developers will be tempted to add more specific interfaces to SpiderMonkey, reducing its genericity in favor of its use in Firefox itself. This will produce less and less useful libmozjs versions, until we reach the point when they ll make the same announcement as above, with s/gtkmozembed/libmozjs/. This is especially relevant in the context of the GNOME Shell, which is at the core of the GNOME 3 experience. The developers deliberately chose to avoid using JavaScriptCore (the JS library inside webkit) through the Seed engine, and used GJS instead, that relies on libmozjs. In my opinion this was done for frivolous reasons (being able to use more language extensions); and not only this put the GNOME developers in an awkward situation where 2 JS interpreters compete in the same desktop, but now it puts a risk on a technology which is at the core of the desktop. One of the reasons for the limited adoption of JSCore is that it lies currently in the same library as Webkit, which is a huge dependency. I ve been very glad to learn that Gustavo is considering the idea of splitting it. We need to provide an escape route for applications using libmozjs, and it looks like more than a decent one. I hope that GNOME Shell follows it sooner than later.

A few weeks ago, at work, we were looking for a solution to a tricky printing problem: how to manage, in a centralized infrastructure, a large number of locations, worstations and printers? One of the consultants working for us came up with a great idea. With only a 20-line patch to CUPS, workstations would be able to find which printers are on the same location. 20 lines of code, instead of a complex virtualisation solution? This is exactly the kind of reasons why we use free software: when there s something wrong, you can fix it. When you need something more, you can code it. Now, many others could benefit of such an improvement, and we don t want to maintain a forked version of CUPS, so we forwarded it upstream, who looked interested. But upstream now being Apple, they requested a stupid copyright assignment agreement. I will leave to the reader s imagination the complexity of getting such a document signed in a Fortune 500 company with no business with Apple. This will, of course, not happen - and if the decision was mine, the answer would have been a clear No. No, because I want to improve free software, not to contribute to Apple s proprietary version. No, because copyleft is about giving as much as you take. How many contributions are being left out of CUPS because of this stupid copyright assignment? It looks to me that such software is doomed to remain crippled as long as companies like Apple are in charge of their maintenance. There is free software. And there is free software by Apple. And Oracle. And Canonical.

At first, it looked nice: But then, it was more like:

My only contribution will be: merry FSMas to all!

We ve come a long way since the times when you needed to configure 2 X servers in XDM just to be able to use 2 X sessions at once. However there was still some way to go until recently. A number of bugs that could be wrongly attributed to bugs in the X server or in the desktop environment were actually caused by the display manager doing crap. GDM up to 2.20 Since the introduction of the flexible X servers feature, GDM hadn t evolved much on the matter of user switching. What it used to do was pretty straightforward:

• a specific protocol can be invoked by the gdmflexiserver command;
• the gdm daemon spawns a new X server on an empty console;
• it initiates another login process in it;
• when the session exits, or if the user clicks on Quit instead of logging in, the X server exits.

It is interesting to note that VT (console) switching is purely handled by the X server. When starting, the new server switches the current VT to where it is. When exiting, it automatically switches back to the VT from which it was launched. While very simple, this idea fails to work correctly every time you try to do something more complicated than starting a temporary session for a guest and exiting it. For example, if you start two of them, there is a chance that, when the X server switches back to the console it was run from, there is nothing left running in this console, leaving you with the funny Control-Alt-Fn shortcuts to find your way back to a X server. You will also meet interesting race conditions when trying to switch back to an existing session from the login window. GDM 2.28 and above In the process of rewriting the code entirely, the GDM developers tried to address a number of those shortcomings, making use of D-Bus and ConsoleKit. The new design is slightly more complicated, however.

• The gdmflexiserver tool will first try to look for an existing login window in another X server, and just switch to the VT it is in if it finds one.
• Otherwise, the daemon starts a new slave process with a new X server and a new login window, in a very similar way to what older versions did.
• When logging in as a user with an existing session, it switches to the VT it is in, but leaves the login window and its X server running.
• When going into a new session, the X server is simply left to die at the end of the session, and to switch back to the VT from which it was launched.

Not killing the X server in some cases partly addresses the problems caused by letting it switch back to the original VT when exiting. However in several ways the cure is worse than the disease.

• First of all, it will leave unused X servers, with all processes used by the login window - and that makes quite a number of them, with GDM now using a minimal GNOME session.
• When there is such a login window remaining, ConsoleKit will refuse to let you shut down your computer, being lured into thinking there is someone else using it.
• It doesn t solve the inconsistency issue. When you leave a session, you can find either of: a login window, a screensaver unlock dialog, or a black screen.

Getting it to work The modular architecture of GDM makes it possible to improve the situation. (Possible but not easy because of the millefeuille of classes.) However, it is merely a band-aid unless you fix the root issue: the X server knowing better than you which VT it should switch to when exiting. Fortunately Xorg now features an option to avoid that behavior: -novtswitch. So the first step is to enable it, and let the GDM daemon (or slave) handle VT switching through ConsoleKit. With that, the following changes are possible.

• When switching to an existing session, don t leave a X server behind. You can now kill it safely without risking a VT switch.
• On the opposite, when exiting a session, always respawn a login window on the same VT.
• The last step is to stop making a difference between the first launched X server (called a static server) and the flexible servers. The only remaining difference between a static display and a flexible one is that the static one honors automatic login/timed login settings.

The result With all these changes the behavior of the display manager is finally completely consistent.

• When exiting a session, regardless of it, you always find the same login window.
• There is never an unused process left.
• You will never find yourself facing a black screen with only keyboard shortcuts to leave you out of it.

Interestingly enough, this is very similar to what user switching looks like on Vista or MacOS X. So what now? These changes are stabilized for Debian squeeze, but of course it has been long overdue to get them accepted upstream, along with the very large number of Debian-specific changes that still lie in our packages.

If you use pbuilder, you probably already use cowbuilder too, in order to save on chroot instantiation time. You also probably use ccache in order to save on compilation time. If you do that, the longest time taken by your build is, by far, the time needed to install the build-dependencies, because dpkg likes to fsync() every file it writes. It s a good thing it does that on your main system, but in a disposable chroot you really, really don t care what happens to it if the system crashes. Thanks to Mike, I discovered eatmydata, and tried it with cowbuilder. If you want to try it out, add this to your pbuilderrc file:

EXTRAPACKAGES="eatmydata"
if [ -z "$LD_PRELOAD" ]; then
  LD_PRELOAD=/usr/lib/libeatmydata/libeatmydata.so
else
  LD_PRELOAD="$LD_PRELOAD":/usr/lib/libeatmydata/libeatmydata.so
fi
export LD_PRELOAD

You will also need to install eatmydata in your chroot, unless you want to regenerate it from scratch. And now you can enjoy your super-fast builds.

My wife has been pestering me for months to get a replacement for our dead Epson inkjet printer (which didn t last long, mind you). To avoid the nightmare of printer support, which, unless you buy a high-end professional printer which does everything plus the coffee, is usually somewhere between disaster and works sometimes , we spent a long time on manufacturers websites to choose wisely the model. We chose the HP Laserjet P1102, which, according to HP, has a full support level and is even part of their recommended models. Yet, after plugging it in, it took me quite some time to understand why it would behave as a brick instead of a printer. First, I thought it was a bug in hplip. Then, I soon discovered that the printer advertised itself as a storage device instead of a printer. What, a buggy firmware? Thanks to a random question on Launchpad I discovered it s not a bug, it s a feature. It s named HP Smart Install and it turns out it s yet another stupid idea to support OSes that are too dumb to detect your printers automatically: the printer advertises itself as a CD drive, until you install the driver that will make it switch back to being a printer. What happens to those who don t want this feature that turns your printer into a 10 kg, read-only USB drive? Well, HP has a solution in the Smart Install FAQ:

25. Can I turn HP Smart Install off or on?
Yes. You can use the HP Smart Install utility to disable/enable HP Smart Install. The utility is stored on the software CD, in the UTIL folder. SIUtility.exe is for 32-bit operating systems and SIUtility64.exe is for 64-bit operating systems.

Bunch of idiots. If I buy a 100 printer, it s not so that I have to buy a 100 operating system just to activate it.

Several people asked me for the slides I presented Saturday at the Mini Debconf. Until they are available on the Debconf website, here they are: Despite having gone completely overboard with the timing (let me apologize again to the organizers), the talk seems to have gathered quite some interest. Several people looked surprised to learn Debian is used on such a large scale.